Skip to content

Add hint when if or unless is followed by do#244

Open
schneems wants to merge 1 commit intomainfrom
schneems/if-do
Open

Add hint when if or unless is followed by do#244
schneems wants to merge 1 commit intomainfrom
schneems/if-do

Conversation

@schneems
Copy link
Collaborator

@schneems schneems commented Jan 21, 2026 •
edited by eregon
Loading

A typo in RSpec is typing if instead of it. Depending on the font, they can be hard to distinguish at a glance:

if "does something" do  # Should be `it "does something" do`
  # ...
end

This results in a confusing "Unmatched keyword, missing 'end'?" error because both if and do require their own end. And some keywords like while and loop take do, so it's not always obvious that if or unless don't.

The message needs to accommodate a scenario where it's unknown if the value inside accepts a block like:

if method_call do
end

This might be perfectly valid ruby code, so you wouldn't want to assert "if does not take a do" (since that's not the problem...the problem is that both if and do require an end to close, but the code doesn't provide that.

Before:

Unmatched keyword, missing `end' ?

  2  describe "something" do
> 3    if "does something" do
> 5    end
  6  end

After:

Unmatched keyword, missing `end' ?
Both `if` and `do` require an `end`.

  2  describe "something" do
> 3    if "does something" do
> 5    end
  6  end

Close #206

@schneems schneems marked this pull request as ready for review January 21, 2026 03:10
@schneems schneems mentioned this pull request Jan 21, 2026
Merged
@schneems
Add hint when if or unless is followed by do
a4c04e6 
A typo in RSpec is typing `if` instead of `it`. Depending on the font, they can be hard to distinguish at a glance:

```ruby
if "does something" do  # Should be `it "does something" do`
  # ...
end
```

This results in a confusing "Unmatched keyword, missing `end'?" error because both `if` and `do` require their own `end`. And some keywords like `while` and `loop` take `do`, so it's not always obvious that `if` or `unless` don't.

The message needs to accommodate a scenario where it's unknown if the value inside accepts a block like:

```ruby
if method_call do
   end
```

This might be perfectly valid ruby code, so you wouldn't want to assert "if does not take a do" (since that's not the problem...the problem is that both if and do require an `end` to close, but the code doesn't provide that).

Before:

```
Unmatched keyword, missing `end' ?

  2  describe "something" do
> 3    if "does something" do
> 5    end
  6  end
```

After:

```
Unmatched keyword, missing `end' ?
Both `if` and `do` require an `end`.

  2  describe "something" do
> 3    if "does something" do
> 5    end
  6  end
```

Close #206
@Earlopain
Copy link
Contributor

Earlopain commented Jan 21, 2026

I don't have much expertise but

both if and do require their own end

In the rspec case, you can't insert end anywhere to make it valid. If you do, the string literal takes the block, which is also bad syntax. If I read that message, that's how I would try to fix it.

But I don't have an idea how to spell it differently.

@schneems
Copy link
Collaborator Author

schneems commented Jan 22, 2026

Thanks for the look!

In the rspec case, you can't insert end anywhere to make it valid. If you do, the string literal takes the block, which is also bad syntax. If I read that message, that's how I would try to fix it.

Good call. I'm also not sure how to make it better either, but I'll think on it.

One option could be specializing it for literals (strings, arrays, numbers), those are reliably detectable, but any bareword could be a method. Curly brackets {} could be a hash, or could be an attempt at a closure {|value| ... } (like if someone is converting between "do" block syntax and curly bracket "lambda" syntax, but they missed some code).

One general difficulty of working in the "we expect to see messed-up source code" space is trying to divine intent from input that we already know is wrong in at least one way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Accidental if instead of a block

2 participants

@schneems @Earlopain